home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1991 / Feb 91 / MacApp.Tech$ 2⁄22⁄91 / 2991-MacApp wish list-Feb91 < prev    next >
Encoding:
Text File  |  1991-03-06  |  13.7 KB  |  225 lines  |  [TEXT/GEOL]

  1. Item    9846117                         17-Feb-91        13:42PST
  2.  
  3. From:   D3085                           Progressive Computing, D Lucky,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. ------------------------------------------------------------------------------
  8.  
  9. Sub:    MacApp wish list
  10.  
  11. To the MacApp development team(s) (and anyone else who cares):
  12.  
  13. Stuff I'd like to see in MacApp:
  14.  
  15. 1)  Make MacApp more of a true Application Framework.  I'd like to see much
  16. more effort put into the development of generic data structure classes (e.g.,
  17. trees, graphs, sets, dictionaries, hash tables, bit maps, matrices, etc.).
  18. Right now, I think of MacApp as an Interface Framework.  I spend the majority
  19. of my time building the data model and its behavior.  The List and SortedList
  20. classes are nice for small numbers of nodes or elements but are not efficient
  21. for larger numbers of nodes.  (By the way, with the current level of
  22. documentation and without source code, I would have never guessed that a TList
  23. is really an array of fancy node references... I originally thought Lists were
  24. linked lists and couldn't figure out how binary searches were done on
  25. SortedLists.)  Also, I'd like to see some of the current data classes
  26. generalized.  I was surprised to see that TAssociation is really a relationship
  27. between two strings instead of two objects.
  28.  
  29. 2)  Models (both internal and external).  An internal model represents the core
  30. behavior of my system.  It does not have any user event handling capabilities
  31. of its own (such as DoXCommand).  It does, however, provide interfaces to those
  32. that do handle user events.  This means that, if the need arises, I can move my
  33. model to another application (possibly on another platform… did I say that?).
  34.  
  35. The external model provides persistency (is that really a word?) across
  36. invocations of the program.  This allows me to be able to save the model in
  37. different ways for different applications.  Also, this let's me start with a
  38. primitive way of saving the objects initially and let's me move to a database
  39. solution later in the game if necessary.  In my scheme, the external model has
  40. intimate knowledge of the internal model but the internal model doesn't know
  41. anything about the external model.
  42.  
  43. TDocument as it currently exists comes close to being the class for the model
  44. but it also contains user event handling.  I'd like to see the current
  45. TDocument pruned to just handle model-related (both internal and external) user
  46. events.  Also, I'd like to see the management of views removed from TDocument.
  47. It can, however, keep the behavior for creating windows when opening the
  48. document and destroying windows when closing a document.  I'd like to see
  49. direct knowledge of views maintained only within windows.  With the
  50. introduction of dependencies (described later), windows and views can install
  51. themselves as dependents of the model or specific objects in the model.  I just
  52. don't see the document needing to have any other knowledge of views.
  53.  
  54. By the way, I don't ever include rendering fields or methods in my internal
  55. model.  I find that one Draw method doesn't fit all the views that want to
  56. render the object.  The alternative of creating multiple Draw methods or adding
  57. parameters to the Draw method to figure out how to render the object keeps the
  58. model in a state of flux as I'm adding views to the application.  I want to get
  59. the behavior of the model working first and then add the user interface.  The
  60. downside of this approach is that I have to create view-type objects that
  61. represent the model objects.  Each view that renders model objects owns a set
  62. of these view-type objects.  This partitioning of a model object into both a
  63. model object and a view-type object provide a clearer picture of
  64. responsibilities even though there is memory consumption for object overhead
  65. for each view-types object created.
  66.  
  67. What do I gain from all of this?  A layered approach to building systems.  The
  68. internal model is the foundation while the external model, document, and views
  69. are on top.  When I add/modify views, change the document, or change the
  70. external model, then nothing else should be touched unless the internal model
  71. must be modified to handle those changes.  If the internal model changes,
  72. however, then everything else in the system may have to be modified.  I don't
  73. see this ripple effect, though, as anything more difficult than I do with the
  74. current MacApp architecture.
  75.  
  76. 3)  Different command structure.  I think of a command as a unit of operation.
  77. In other words, multiple operations may be performed to one or more objects
  78. with a command.  Within each operation, I would like to be able to fire off
  79. other commands.  These nested commands, then, may kick off still more commands
  80. (ad nauseum).  Only the commands that are the furthest nested can actually
  81. cause a change to an object.  For example, I catch a user event through a
  82. DoXCommand and, just for grins, its an undoable command so I create a command
  83. object.  The undoable command's DoIt now gets control.  The purpose of this
  84. command is to modify two objects.  Instead of calling the modification methods
  85. of those objects directly, I create two new commands.  Each of these commands
  86. has a name that is similar to the object that is being modified.  The DoIt
  87. methods of these two commands are then executed which, in turn, call the
  88. appropriate modification methods for that object.  The creation of these
  89. "object commands" is extra overhead but I feel that it provides better
  90. accountability of which commands are the "gateways" to the object and it
  91. provides for finer granualarity of commands.  To make this all work, I'd like
  92. each command object have a set of commands.  This would be easy if I had a set
  93. class (yea, I know, I could use TList but it's not precise).
  94.  
  95. If I haven't befuddled you yet, I'll try again.  In the example above, I've
  96. specified two different types of commands:  The user event command and the
  97. model command (i.e., the two nested commands).  Since I've advocated this tight
  98. coupling between commands and the object they modify, it seems that the command
  99. classes should be integrated into the object classes (e.g., view, model, etc.)
  100. so objects can be more of a "black box".  Kinda sounds like multiple
  101. inheritance can be used for this purpose.  For example, TMyView could inherit
  102. from TView and TMyCommand.  This oughtta drive MacBrowse bananas.
  103.  
  104. 4)  Dependencies (both simple and command).  My definition of a simple
  105. dependency is one where a sponsor object issues a Changed (or some such)
  106. message to himself which, in turn, issues Update (or some such) messages to
  107. each of the objects in his dependency set.  I then stick my calls to Changed
  108. within my Set methods.  Now every time I modify an object, all of its
  109. dependents are notified.
  110.  
  111. Propogating commands seems to be stickier.  I'd like to have a way to have a
  112. sponsor notify dependents to execute a command rather than a simple update.
  113. There are a few ways to do this.  The first is to use a parameter of Update to
  114. indicate the type of operation (DoIt, UndoIt, RedoIt, Commit).  The problem
  115. here is that I can see the possibilities of some pretty big case statements for
  116. Update.  The second is to have multiple update-type messages.  I can imagine
  117. there are a number of other schemes that can be used.
  118.  
  119. 5)  Use of a language that provides multiple inheritance capabilities and class
  120. variables and use those capabilities.  At this time it's C++.  Maybe tomorrow
  121. it's Pascal 9x.  I'll put up with the warts of either language to get this
  122. capability.  I think that it is much more natural to use multiple inheritance
  123. to design classes than to resort to the present methodology.  You know the
  124. drill. Pick the class with the most commonalities and create a subclass of that
  125. type.  In the initialization routine, create objects of the other classes and
  126. stash their reference in the object.  There are two problems that I have with
  127. this approach.  The first is that it just doesn't seem natural.  The second is
  128. that I have to write little bridge methods for all of methods of the other
  129. classes unless I break encapsulation by calling the methods of the other
  130. classes directly (e.g., A.B.Method).  Then again, maybe I'm the only one that
  131. thinks that these sort of method invocations defeats the purpose of "black-box"
  132. objects.
  133.  
  134. I'm not much for religion about languages, environments, libraries, operating
  135. systems, or machines.  I like the old saying, "If all you have is a hammer,
  136. then the whole world looks like a nail."  While I'm haven't yet mastered all
  137. the intracacies of C++, I think it provides much more power and flexibility
  138. than Object Pascal.  It also allows me to hang myself and write some pretty
  139. rotten code but that's part of my maturation process with a new language.  I
  140. can write cryptic code in any language but one the measures of my skill as a
  141. software engineer is to write maintainable code (whatever that really means).
  142. Also, I don't need a mastery of C++ for MacApp 3.0 to understand what's going
  143. on.  All I need is to be able to read the code and understand what's going on.
  144. That's far different than the mastery of C++ that I need when designing classes
  145. in C++.
  146.  
  147. If I have a language choice between C++ and Pascal 9x, then I'll pick C++ for
  148. purely strategic reasons.  If I use C++, then I can choose class libraries that
  149. run on multiple platforms.  If I choose OP/Pascal 9x, then I'm limited to only
  150. Macintosh libraries.  This view might be different if Pascal 9x were to become
  151. a standard across platforms and had a better selection of class libraries.
  152.  
  153. 6)  Perform iterations over lists differently.  Since C++ doesn't have nested
  154. procedures, coding pascal-type "callback" functions that are the target of Each
  155. can be extremely painful.
  156.  
  157. 7)  Keep distributing the source.  I'd like to see better documentation for the
  158. MacApp class methods on paper, a more complete cookbook, and more complex
  159. tutorials but I couldn't tell you the sort of documentation that would be
  160. required before I wouldn't need the source.  I don't, however, think that I
  161. need to know about fields if you provide me all the methods to interrogate and
  162. modify MacApp objects.
  163.  
  164. I'd like the source for a few reasons.  First, sometimes I want to really know
  165. how things are being done.  This is a last resort when the documentation
  166. doesn't tell me what I need to know because I can spend a huge amount of time
  167. learning the fine details.  The second is that I sometimes fix bugs in the
  168. code.  I don't create bug-free code and I don't expect it from Apple.  I don't
  169. believe we've reached the point where we can guarantee code with zero defects.
  170. My problem is that I sometimes need immediate turn around time for the fix.
  171. Apple doesn't provide nor do I expect this kind of service.  The third reason
  172. is that I may want to modify the behavior of a MacApp class.  I realize that
  173. Apple cannot be held accountable for any problems I create.
  174.  
  175. 8)  If necessary, provide System 7.0 capabilities in a MacApp 2.x (this number
  176. used only for a forward reference…  the version number doesn't matter to me)
  177. release done in Object Pascal ASAP.  Afterwards, add my recommendations (yuk,
  178. yuk) as well as your own to the next release done either in C++ or Pascal 9x.
  179. The change to a new architecture is sure to break everyone's code in any
  180. language so we can all suffer together.  Those that do want a new architecture
  181. can upgrade and those that don't can continue to use the 2.x version.  I fully
  182. expect that the 2.x version wouldn't be supported by Apple when the next
  183. release becomes production.
  184.  
  185. 9)  Get the C++ team to include the new parameterized types and exception
  186. handling mechanisms implemented ASAP.  Also, get them to fix the problem with
  187. multiple inheritance of Handle-type classes.  I think I understand why C++
  188. won't currently do multiple inheritance on these classes but more effort really
  189. needs to be committed to solving this problem.
  190.  
  191. 10) I'd like to know the short, medium, and long range goals, strategies, and
  192. tactics that Apple has concerning OO technology and MacApp.  My decision to use
  193. MacApp includes both technical and strategic issues.  The feeling that I get
  194. from Apple is that, as a developer of products for the Macintosh (an Apple
  195. "Partner"), I am important in their strategy.  Apple has already made the
  196. decision that they would discuss future products and directions with developers
  197. when System 7 was announced over a year and a half ago.  If I knew more about
  198. where Apple is going, I might even be able to help out with auxillary tools for
  199. MacApp.  Without clear signals, though, I'm afraid to enter any domain that
  200. Apple currently touches.  For example, I was close to completing a product that
  201. was terminated by others when Apple announced System 7.  I really don't want to
  202. go through that again.  I think the speculation about where Apple is going can
  203. be interesting and informative but can be exceedingly dangerous!  I feel that
  204. the lack of information from Apple is causing the flock to stray.
  205.  
  206. I feel that Apple could do more in keeping me informed of what it's doing
  207. without giving away the store.  For example, it kinda sounds like the
  208. requirements and design of MacApp 3.0 have been decided but I don't recall them
  209. asking me what I thought should be included.  Matter of fact, I don't recall a
  210. statement from Apple explaining the requirements and design.  This causes me to
  211. think that I'm shut out of the planning process.  One of the reasons for
  212. writing this KC burner is to let Apple know what I think anyway.  Bear in mind
  213. that I don't think that suggestions I make have to be implemented.  I would,
  214. however, like for Apple to solicit my opinions and let me know of the
  215. disposition (with reasons) of these suggestions.  There doesn't have to be
  216. anything formal about it either.  An informal message in a Link would be okay.
  217.  
  218. I'm already on the MacApp bus but I'd like to know where it's headed.
  219.  
  220. Stirring the pot with an outboard motor...
  221.  
  222. I think I'm still,
  223. Dave Lucky
  224.  
  225.